Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-svrloc-protocol-02.txt < prev next >

Wrap

Text File | 1993-10-19 | 47.1 KB | 1,133 lines

draft-ietf-svrloc-protocol-02.txt John Veizades INTERNET-DRAFT FTP Software, Inc. Scott Kaplan FTP Software, Inc. October 14, 1993 Service Location Protocol 1.0 Status of this memo This draft document is a product of the IETF Service Location Working Group; it will be submitted to the RFC editor as a standards document. Please respond with comments to the srvloc@ftp.com mailing list. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. 2.0 Abstract The service location protocol provides a framework for the discovery and selection of network services. It relies on multicast support at the network layer of the protocol stack it is using. It does not specifically rely upon the TCP/IP protocol stack but makes use of concepts that are found in most TCP/IP protocol implementations. Traditionally, users find services using the name of a network host (a human readable text string) which is an alias for a network address. The service location protocol eliminates the need for a user to know the name of a network host supporting a services. Rather, the user supplies a set of attributes which describe the services. The services location protocol allows the user to bind this description to the network address of the service. Service Location WG Expires April 15, 1994 [Page 1] INTERNET-DRAFT Service Location Protocol Oct-93 Table of Contents 1.0 Status of this memo..............................................1 2.0 Abstract.........................................................1 3.0 Notation Conventions.............................................3 4.0 Terminology......................................................3 5.0 Protocol Overview................................................3 5.1 Service Location PDU header..................................4 5.1.1 Version................................................4 5.1.2 Functions..............................................4 5.1.3 Length.................................................5 5.1.4 Locale.................................................5 5.1.5 Flags..................................................5 5.1.6 XID....................................................5 5.1.7 Error Codes............................................5 5.1.8 Authentication Information.............................5 5.2 Distinguished Attribute Query................................6 5.3 Get Attributes Query.........................................7 5.4 Service Query................................................8 6.0 Directory Agents.................................................9 6.1 Introduction.................................................9 6.2 Directory Agent Discovery....................................9 6.3 Service Registration.........................................9 6.4 Service Unregister..........................................10 6.5 Directory Agent Clusters....................................10 6.6 Foreign Directory Agent Discovery...........................11 7.0 Service Information Versions....................................11 7.1 Information Versions........................................11 7.2 User Agents.................................................11 7.3 Directory Agents............................................12 7.4 Service Agents..............................................12 8.0 Server Location Connections.....................................12 9.0 Function Resolution.............................................13 10.0 Authentication.................................................13 11.0 Multicast vs. Broadcast........................................14 11.1 Non-interneted networks...................................14 11.2 Interneted site...........................................14 12.0 Packet formats.................................................15 12.1 Attributes................................................15 12.2 Attribute Value List......................................16 12.3 Service Instance..........................................16 12.4 Predicate.................................................17 13.0 Predicate Language.............................................17 14.0 Interesting Constants..........................................18 15.0 Acknowledgments................................................19 16.0 References.....................................................19 17.0 Author's Address...............................................20 18.0 Document Expiration............................................20 Veizades, Kaplan [Page 2] INTERNET-DRAFT Service Location Protocol Oct-93 3.0 Notation Conventions <> Values set of in this manner are fully described in section 12.0. | | \ \ Packet layouts with this notation indicate a variable length | | field. 4.0 Terminology User Agent a process working on the user behalf to acquire service attributes and configuration. The user agent retrieves service attributes and configuration from the service agents. Service Agent a process working on the behalf of one or more services to advertise service attributes and configuration. Service Instance a collection of attributes and configuration information associated with a single service. The service agents advertise service information for a collection of service instances. Service a process or system providing a facility to the network. The goal of service location is to provide sufficient information to the user, via the user agent, to find the service. The service itself is out of band of the service location protocol. Directory Agent a process which collects information from service agents to provide a single repository of service attributes and configuration. Distinguished Attribute an attribute at the top level of the service location naming taxonomy. This attribute is registered with IANA. Attribute a {class, value} pair describing a characteristic of a service Predicate a boolean expression of attribute 5.0 Protocol Overview The following describes the operations a service location end system needs to find services on the attached network. The end systems does not need any configuration to begin network interaction. The end Veizades, Kaplan [Page 3] INTERNET-DRAFT Service Location Protocol Oct-93 system builds on the information it retrieves in earlier network requests to find the agents advertising service information, then finds the terms used to describe services that it is interested in. The end system can use this information to send out predicates which describe the service that match the user's needs. The service location protocol is UDP multicast/broadcast based. Since the requester does not know the number of responses to a request and the request may generate more responses than the requester is able to handle, the requester sends a series of requests. Each request contains the information learned in the previous requests. The protocol requires responders to scan this list and respond only if they have information not in the list. Responses are multicasted at a pseudo-random interval giving other responders the opportunity to see responses and save network traffic by not responding with redundant information. Character strings are represented as a {type, length, value} tuple. Implementers of this specification are strongly encouraged to be able to send and receive Unicode [17] as one of the string data types. 5.1 Service Location PDU header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version = 1 | function | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | locale | flags | XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Auth length | Auth Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Authentication Information> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.1 Version This protocol document defines version 1 of the service location protocol. 5.1.2 Functions Service location datagrams can be identified as to their operation by the function field. The following are the defined operations: Distinguished Attribute Request DistAttrRqst 1 Distinguished Attribute Reply DistAttrRply 2 Attribute Class Request AttrRqst 3 Attribute Class Reply AttrRply 4 Veizades, Kaplan [Page 4] INTERNET-DRAFT Service Location Protocol Oct-93 Service Request SrvRqst 5 Service Reply SrvRply 6 Service Unregister SrvUnreg 7 Service Acknowledge SrvAck 8 Version Request VerRqst 9 Version Reply VerRply 10 Function Resolve Request FuncReslvRqst 11 Function Resolve Reply FuncReslvRply 12 5.1.3 Length The length is the number of bytes after the header field. 5.1.4 Locale All service location requests and responses contain the "locale" field. This allows clients to advertise their preference as to the language in which responses should be returned. The locale is defined as the ISO ****need reference here**** Services should have a default locale and if they are able to respond in a language that meets the clients needs they should respond with data in the client's locale otherwise they should respond with data in their default locale. 5.1.5 Flags The flags field is a bit field. The only defined value for this bit field is the overflow bit (bit 0). See section 8.0 for a complete description for the use of this field. 5.1.6 XID The XID (transaction ID) field allows the requester to match responses to individual requests. Retransmission of the same service location datagram should not contain an updated XID. The requester creates the XID an initial random seed and changes it for each request it makes. The responder copies the XID from the request into its response. 5.1.7 Error Code Errors are only valid in response datagrams. Responses that completed successfully should have a null value for the error code. 5.1.8 Authentication Information The service location protocol makes provisions for the inclusion of authentication information. The service agent may use the authentication information to allow or deny access to the service information. This is not a security architecture for services. The service agent only provides security for service information. Users who rely on this level of security to secure service access are depending on security through obfuscation (i.e. if I don't tell you where it is, you can't find it). Authorization and access control should also be added to the service access point. Veizades, Kaplan [Page 5] INTERNET-DRAFT Service Location Protocol Oct-93 to the service access point. User agent should use this level of security to verify that the send of the information that they are relying on is an authorized provider of this information. Service location allows for the support of several styles of authentication. Authentication is encoded in the PDU with type and length values. The values for the authentication types are yet to be determined. 5.3 Distinguished Attribute Query The client uses the Distinguished Attribute Request to find all the types of services that are available on a network. Service agents respond with a list of Distinguished Attributes that they support. Like most service location PDUs, a client can issue more than one request to insure that all replies have been received. In each subsequent request, a user agent adds the list of distinguished attributes that it is aware of in the "distinguished attributes found" field of the datagram. Service agents look for distinguished attributes that they support but are not in the list. If any such distinguished attributes exist, the service agent replies with these distinguished attributes. The number of distinguished attributes the service agents returns is in the datagram as "distinguished attributes found". The service agent should wait before responding. The wait time should be a random interval between 0 and 10 seconds divided by the number of distinguished attributes in the response. User agent requests that are generated by a genesis event, i.e., rebooting of a system, loading of the network kernel, etc. should be sent after a random interval between 0 and 10 seconds. A distinguished attribute defines a class of objects of a particular type, i.e., printers, modems, file servers, etc. These attributes are registered through the Internet Numbering Authority (IANA). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = DistAttrRqst) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Distinguished Attributes found | <Distinguished Attribute> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Distinguished Attribute> (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Distinguished Attributes Request Veizades, Kaplan [Page 6] INTERNET-DRAFT Service Location Protocol Oct-93 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = DistAttrRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | number of Dist Attrs returned | <Distinguished Attribute> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Distinguished Attribute> (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Distinguished Attributes Reply 5.4 Get Attributes Query Once a user agent selects a distinguished attribute, it sends a "get attributes request" to find all the attributes associated with that distinguished attribute. Since different instances of a particular distinguished attribute can support different attributes, to find all the attributes associated with a distinguished attribute, the user agent must form a union of all attributes returned by all service agents. The user agent may drop some of the replies. It can get the attributes from these service agents by re-issuing the request. The user agent places the addresses of the service agents that it already has replies from in the "service addresses" field of the request. Service agents should only reply if they are not on the "service addresses" list of the request. With a packet length of 1500 bytes, this protocol can support ~200 IPv4 respondents. Networks with greater than 200 service agents need to install a directory agent (see Section 6.0). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = AttrRqst) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | number of services found | <Dist Attr> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Dist. Attr> (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Service Addresses> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attributes Request Veizades, Kaplan [Page 7] INTERNET-DRAFT Service Location Protocol Oct-93 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = AttrRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | number of Attrs returned | <Attribute Value List> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Attribute Value List> (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attributes Reply 5.5 Service Query Having retrieved the attribute grammar which the service agents use to describe services, the user agent can build a query predicate that describes the service needs of the user. The query is multicast to all service agents or unicast to service agents that support the indicated distinguished attribute. Service agents that can satisfy the predicate, reply with the attributes that they used to satisfy the predicate. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = SrvRqst) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Predicate> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = SrvRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Service Instance> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Attribute Information> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Reply Veizades, Kaplan [Page 8] INTERNET-DRAFT Service Location Protocol Oct-93 6.0 Directory Agents 6.1 Introduction A directory agent acts as an proxy for many service agents. It acquires information from service agents and acts as a single point of contact to supply that information. Service agents register information with the directory agent so it can reply to service location requests the way that the service agent would. The directory agent should be able to respond in a timely fashion to user agent request and contain accurate information about the services that are being advertised by the service agent. The queries that a user agent uses with the service agents (i.e. an environment without a directory agent) are the same queries that the user agent unicasted to the directory agent. A user agent may cache information about the presence of other directory agents to use as fall back directory agents in case a selected directory agent fails. 6.2 Directory Agent Discovery When a directory agent first comes on line it sends an unsolicited distinguished attribute reply to the multicast address. Service agents upon receiving this reply must wait for a random interval and then begin registration of each of the services that the service agent advertises. When a service agent or user agent first comes on-line it issues a service request for the distinguished attribute "DIR AGENT"; directory agents reply to this query. A service agent should look at the authorization information returned and determine if the directory agent is an authorized agent. The service registers information with all directory agents when either of the above two events take place. A directory agent may cache information registered with it over boot cycles. If it does it must verify this information using the service instance information version see section 7.0. 6.3 Service Registration After a service agent has found a directory agent, it begins to register its advertised services one at a time. A service agent must wait for some random time between each registration. Registration is done using the service reply packet specifying all attributes for a service. A directory agent must acknowledge each service registration request. Service registration may use a connectionless protocol (e.g. UDP). But the registration operation may contain more information than can be sent in one datagram. The service registration operation can be sent in more than one register operation, the service agent registers attributes that fit in one datagram and then continues to register additional attributes in additional registration operations. When a service agent registers the same attribute class more than once for a service instance, the Veizades, Kaplan [Page 9] INTERNET-DRAFT Service Location Protocol Oct-93 directory agent overwrites the all the values associated with that attribute class. The directory agent may return a server error in the acknowledgment. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = SrvAck) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code (0 = no error) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Acknowledgment 6.4 Service Unregister When a service is no longer available for use, the service must unregister itself from directory agents that it has been registered with. A service uses the following PDU to unregister itself. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = SrvUnreg) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Service Instance> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Unregister The service agent should retry this operation if there is no response from the directory agent. The directory agent acknowledges this operation with a service acknowledgment. 6.5 Directory Agent Clusters Directory agents may form clusters. A cluster of directory agents defines a union of the database of each directory agent in the cluster. Each directory agent answers requests based on the information in the united database. Therefore, each directory agent will give the same reply to a given response. This is useful when the horizon which a user or service agent can see is smaller than the services which it normally wants to access. There is currently no protocol support for clusters. An administrator has to configure each directory agent with the network address of the other directory agents in the cluster. There is also no support for creating the union of the database other than the existing service location PDUs. Veizades, Kaplan [Page 10] INTERNET-DRAFT Service Location Protocol Oct-93 6.6 Foreign Directory Agent Discovery Finding foreign directory agent allows a user agent to discover services in a remote domain. How the user agent finds the remote directory agent is not specified in this protocol. This is in the purview of wide-area naming or directory services. The user agent will need the name of the foreign directory agent in the naming/directory service's namespace. 7.0 Service Information Versions Service location information can live in three locations: at the service agent, the directory agent and/or the user agent. A service agent has the authoritative version of the service information. The directory agents and the user agents have copies of the service agent's information. The "information version" provides an indication to the user and directory agents that the copies that they hold are out of sync with the authoritative database in the service agent. 7.1 Information Versions For every service instance advertisement, the service agent attaches an information version to the advertisement. This version number is a way for the service agent to tag the current state of the information that it is advertising. When this information changes, the service agent increments the version. Agents that are caching this information can ask the service agent for the version of the current database. 7.2 User Agents When a user agent caches information that it has received from a service agent or directory agent it should get the version number from source before it uses the cached information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = VerRqst) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Service Instance> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version Request Veizades, Kaplan [Page 11] INTERNET-DRAFT Service Location Protocol Oct-93 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = VerRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version Reply The information may be invalid for several reasons. The service agent may not exist, the service instance may no longer exist or the user may not be authorized to use the service. Error values are returned for all the above reasons. When an error is received a user agent must invalidate the cached information. A user agent may try to revalidate the information using the original query predicate. When an error is received a user agent must invalidate the cached information. A user agent may try to revalidate the information unicasting the original predicate to the service agent or may try to reacquire a service provider multicasting the original predicate. 7.3 Directory Agents Directory agents must return correct information since they are acting on behalf of service agents. Service agents must update directory agents when their databases change. However, directory agents cannot rely on service agents to always keep them updated. Directory agents must verify the validity of the information that they advertise by requesting the service version from the service agent. Information that cannot be validated should not be advertised. A directory agent can get the information version synchronously or asynchronously. 7.4 Service Agents Service agents advertise information that they authoritatively own. When a service agent advertises information, it also indicates the information version. When the service agent registers with a directory agent, the service is responsible for updating the directory agent when the information changes at the service agent. 8.0 Server Location Connections When a service location request results in a reply from a service or directory agent that will overflow a datagram, the user agent can open a connection to the agent and reissue the request over the connection. The response will be received over the same connection. A directory or service agent indicates an overflow via the overflow flag in the service location packet header. The operations that can overflow are the attribute reply and the service reply. This operation requires the implementation of a reliable byte stream protocol, like TCP, by the user, service, and directory agents. The service agent is not required to implement a reliable byte stream protocol, but if it doesn't, it Veizades, Kaplan [Page 12] INTERNET-DRAFT Service Location Protocol Oct-93 can't set the overflow bit (i.e. its answer must fit in a datagram). 9.0 Function Resolution The attribute value of an attribute can be a function. A function is a handle for a rapidly changing attribute value that must be resolved at the service agent (e.g. a piece of code that the service agent runs to determine an attribute like whether a service is on-line). The function data that is passed to the service agent is an opaque value that allows the service agent to identify the method to determine the attribute values. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = FuncReslvRqst) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Distinguished Attribute> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Function Resolve Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service location header (function = FuncReslvRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Length |S| Attr Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Attribute Value> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Function Resolve Reply 10.0 Authentication The following discussion of authentication and security is based on premise that a security and authentication policy has been implemented for the site. The service location protocol can function independent of any site specific authentication policy. The security and authentication policies need to address three areas; data integrity, data origin authentication and data confidentiality. That is to say that the data that is advertised has not been subject to tampering, that the origin of the advertised information can be Veizades, Kaplan [Page 13] INTERNET-DRAFT Service Location Protocol Oct-93 corroborated and that the data advertised can be protected from unauthorized viewing. Service location does not make any provisions for protection from unauthorized viewing of data and it is left to the network layer of the protocol to support this functionality. A service can place restrictions on information that is given out to user agents and this level of security should be maintained when this information is registered with a directory agent. A service agent also needs some level of assurance that the directory agent is a trusted entity. Any security mechanism that is used with service location should allow the service agent to verify that the directory agent is authorized to act upon its behalf. This security mechanism should also allow for the directory agent to verify that the service agent is a valid source for the information that it is providing. From the user agent's perspective it must be able to verify that the directory agent is an authoritative source of information and in turn the directory agent must confirm that the user agent is a valid member of the community. All these functions can be implemented using the authentication architecture with in service location using one of the many authentication schemes already in place, i.e., Kerberos, MD5, etc. 11.0 Multicast vs. Broadcast The service location protocol was designed for use in networks where multicast at the network layer is supported; in some instances multicast may not be supported. To support this protocol in networks where multicast is not supported the following modifications are made to support the protocol in an environment where network layer broadcast is supported. 11.1 Non-interneted networks If a network is not connected to any other networks simple network layer broadcasts will work in place of multicast. 11.2 Interneted site The directory agent provides a central clearing house of information for end systems. If the network is designed so that a directory agent address is configured with each end system, the directory agent will act as a bridge for information that resides on different subnets. The directory agent address can be configured with end systems using a protocol like the IP Dynamic Host Configuration Protocol. Veizades, Kaplan [Page 14] INTERNET-DRAFT Service Location Protocol Oct-93 12.0 Packet Formats 12.1 Attributes 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length |S| Std. Auth. | Attr. Type | <Attr Class> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Attribute Class> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Attribute Value> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length The number of bytes in the attribute, including the length field S bit set if the attribute is a standard attribute Standardization Authority A number assigned to an organization which defines semantics for attributes. (Registered with IANA) Attribute Type 1=Distinguished attribute 2=String 3=Integer 4=Function 5=Boolean Attribute Class <string> Attribute Value <string> (Attr. Type = 1|2) <integer> (Attr. Type = 3|4|5) Attributes are {class, value} pairs that define a characteristic of a service. There are three classes of attributes: distinguished attributes, standard attributes and regular attributes. The distinguished attribute is an attribute with the "attr type" set to one. In addition, the attribute class is a zero length string. Veizades, Kaplan [Page 15] INTERNET-DRAFT Service Location Protocol Oct-93 12.2 Attribute Value List 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length |S| Std. Auth. | Attr. Type | num values | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Attribute Class> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Attribute Value> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12.3 Service Instance 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Address length|Srv Info Length| <Address> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Address> (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Service Info> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Instance A service instance is the address of the service in question, the port of the service access point and any additional service specific information needed to make the service connection. A service address is typed to support a variety of network protocols. The service specific information may be service layer protocol specific information that facilitates the service rendezvous. Veizades, Kaplan [Page 16] INTERNET-DRAFT Service Location Protocol Oct-93 12.4 Predicate 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pred length | <Predicate> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ <Predicate> \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Predicate 13.0 Predicate Language <attr expr> ::= <attr class> <template value> | <bool op> <attr expr> <attr expr> | '!' <attr expr> <bool op> ::= '&' | '|' <template value> ::= <cond op> <integer value> | '=' <string template> | '=' <attr function> <string template> ::= 'S' <length> ['*'] <characters> ['*'] <attribute> ::= <attr class> <attr value> <attr value> ::= <string value> | <integer value> | <attr function> <attr class> ::= <string> <string value> ::= 'S' <string> <integer value> ::= 'I' <integer> <attr function> ::= 'F' <integer> <string> ::= <type> <length> <characters> <characters> ::= ? <length> ::= <octet> <integer> ::= <4 octet> <octet> ::= <8 bits> <bit> ::= give me a break! <address> ::= <addr type> <length> <value> <addr type> ::= <octet> <value> ::= <variable number of octets> o Spaces, tabs, carriage returns, and line feeds are optional between tokens (i.e. ignored by the recipient) and, since they take up bandwidth, are discouraged. o All string comparisons are caseless, however, a process should preserve the case of a string and store exactly what it receives. Veizades, Kaplan [Page 17] INTERNET-DRAFT Service Location Protocol Oct-93 o <wildcard> matches 0 or more characters. 14.0 Interesting Constants UDP and TCP Port Number To be assigned by IANA Multicast Address To be assigned by IANA Address Types Internet v4 CLNP AppleTalk DecNet ArcNet String Types ASCII 1 ISO646 2 Unicode 3 Attribute Value Types Distinguished Attribute 1 String 2 Integer 3 Function 4 Boolean 5 Error Codes TO BE DETERMINED Authentication Types None 0 MD2 1 MD4 2 MD5 3 Kerberos 4 RSA 5 Plain Text 6 Unix 7 Veizades, Kaplan [Page 18] INTERNET-DRAFT Service Location Protocol Oct-93 15.0 Acknowledgments This protocol owes some of the original ideas to other service location protocols found in many other networking protocols. Leo McLaughlin (FTP) and Mike Ritter (Apple) provided much input into early version of this document. Thanks also to Steve Deering (Xerox) for providing his insight into distributed multicast protocols. 16.0 References [1] Freier, A. O. "Network Binding Protocol" Xerox Corporation Unpublished, June 1986. [2] S. Gursharan, R. Andrews, A. Oppenheimer, Inside AppleTalk. Addison-Wesley Publishing. 1990 [3] Deering, S., "Host Extensions for IP Mulitcasting", RFC 1112, NIC, August 1989. [4] Galvin, J., McCloghrie, K., "Security Protocols for version 2 of the Simple Network Management Protocol", RFC 1446, NIC, April 1993. [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, NIC, April 1992. [6] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, M.I.T. Laboratory for Computer Science, August 1993. [7] Accetta, M. "Resource Location Protocol", RFC 887, NIC, December 1983. [8] Legato Systems, "The Legato Resource Administration Platform", Legato Systems, 1991. [9] C. McManis and R. Rom, "The Zeus Name Service Architecture", Sun Microsystems, 1990. [10] S. Dyer, "The Hesiod Name Server", Winter Usenix Conference, pp. 183-187, Feb 1988. [11] D. Oppen and Y. Dalal, "The Clearinghouse: A Decentralized Agent for Locating Named Objects in a Distributed Environment," Tech. Rep. OPD-78103, Xerox Office Products Division, 1981. [12] B. Lampson, "Designing a Global Name Service", Proceedings of the 5th ACM Symposium on Principles of Distributed Computing, pp. 1-10, 1986. [13] D. Cheriton and T. Mann, "Uniform Access to Distributed Name Interpretations in the V-system". [14] S. Deering. "Router Discovery Protocol". RFC 1256, NIC 1991. Veizades, Kaplan [Page 19] INTERNET-DRAFT Service Location Protocol Oct-93 [15] P. Mockapetris. "Domain Names - Concepts and Facilities". RFC 1034, NIC, November 1987 [16] P. Mockapetris. "Domain Names - Implementation and Specification". RFC 1035, NIC. November 1987 [17] The Unicode Standard Version 1.0 Volume 1, ISBN 0-201-56788-1 October 1991. 17.0 Author's Addresses John Veizades FTP Software, Inc. 785 Market St. 12th Floor San Francisco, CA 94103 Phone: 415-978-2236 Fax: 415-543-9002 Email: veizades@wco.ftp.com Scott Kaplan FTP Software, Inc. 785 Market St. 12th Floor San Francisco, CA 94103 Phone: 415-978-2204 Fax: 415-543-9002 Email: scott@wco.ftp.com 18.0 Document Expiration This document expires April 15, 1994 Veizades, Kaplan [Page 20]